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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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1 Scope 

This Technical Specification defines the Radio Network Layer user plane protocol being used over the lu interface. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] UMTS 25.401, 3"* Generation Partnership Project (3GPP) Technical Specification Group (TSG) 
RAN; UTRAN Overall Description. 

[2] UMTS 25.410, 3"^ Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

RAN; UTRAN lu interface: general Aspects and Principles. 

[3] UMTS 25.413, 3''' Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

RAN; UTRAN lu interface RANAP protocol. 

[4] UMTS 25.414, 3''' Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

RAN; lu Interface Data Transport and Transport Signalling. 

[5] UMTS 23. 1 10, 3"* Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

SSA, UMTS Access Stratum, services and functions. 

[6] UMTS 23. 121, 3''' Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

SSA, Architectural requirements for Release 99. 

[7] ITU-T Recommendation 1.363.2 (1997) - B-ISDN ATM Adaptation Layer type 2 specification. 

[8] ITU-T Recommendation 1.366.1 (1998) - Segmentation and reassembly service specific 

convergence sublayer for the AAL type 2. 

[9] UMTS 25.990, 3''' Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

RAN; Vocabulary. 

[10] UMTS 25.321, 3''' Generation Partnership Project (3GPP) Technical Specification Group (TSG) 

RAN; MAC Protocol Specification. 

[II] UMTS 25.322, 3"^ Generation Partnership Project (3GPP) Technical Specification Group (TSG) 
RAN; RLC Protocol Specification. 

3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Non Access Stratum (NAS) Data Streams: 

Non Access Stratum Data Streams is a generic term to identify these data streams exchanged at the Dedicated Service 
Access Points between the Non Access Stratum and the Access Stratum. 
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RAB sub-flows: A RAB as defined in [9] is realised by UTRAN through one to several sub-flows. These sub-flows 
correspond to the NAS service data streams that have QoS characteristics that differ in a predefined manner within a 
RAB e.g. different reliability classes. 

RAB sub-flows characteristics: 

1) The sub-flows of a RAB are established and released together at the RAB establishment and release, 
respectively; 

2) The sub-flows of a RAB are submitted and delivered together at the RAB SAP; 

3) The sub-flows of a RAB are carried over the same lu transmission connection; 

4) The sub-flows of a RAB are organised in a predefined manner at the RAB SAP and over the lu interface. The 
organisation is imposed by the NAS as part of its co-ordination responsibility. 

RAB sub-flows numbering (applies to support mode for predefined SDU size only): 

1) RAB sub-flows are numbered from 1 to N (N is the number of sub-flows); 

2) RAB sub-flow number 1 corresponds to the highest reliability class and the RAB sub-flow number N 
corresponds to the lowest reliability class; 

NOTE: It is FFS whether numbering of subflows can be based on something else than reliability classes. 

3) RAB sub-flows order inside the lu frame is predefined so that RAB sub-flow number one comes first and the 
RAB sub-flow number N comes last. 

RAB sub-Flow Combination (RFC): A RAB sub-flow combination is defined as an authorised combination of the 
RAB sub-flows variable attributes (e.g. SDU sizes) of currently valid RAB sub-flows that can be submitted 
simultaneously to the lu UP for transmission over lu interface. Each combination is given by the CN and cannot be 
altered by the SRNC. 

RAB sub-Flow Combination Indicator (RFCI): This indicator uniquely identifies a RAB sub-flow combination for 
the duration of the lu UP peer protocol instances i.e. it is valid until the termination of the call or until a new 
initialisation is performed. Usage of RFCI applies only to lu UP protocol operated in support mode for predefined SDU 
size. 

Principles related to RFCI allocation and initialisation procedure: 

1) RFCI value is present in every lu user frame; 

2) In the Initialisation procedure in lu UP, the size of every RAB sub-flow SDU for each RFCI is signalled. 

Syntactical error: A field is defined to be syntactically incorrect in a message if it contains at least one value defined 
as "reserved", or if its value part violates syntactic rules given in the specification of the value part. However it is not a 
syntactical error that a value specified as "spare" is being used. 

Semantical error: A message is defined to have semantically incorrect contents if it contains information which, 
possibly dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the 
procedural part. 



3.2 Abbreviations 



AMR Adaptive Multi-Rate codec 

AS Access Stratum 

CN Core Network 

DTX Discontinuous Transmission 

NAS Non Access Stratum 

QoS Quality of Service 

PDU Protocol Data Unit 

PCE Procedure Control Extension 

PME Procedure Control Bitmap Extension 

RAB Radio Access Bearer 
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RANAP Radio Access Network Application Part 

RFC RAB sub Flow Combination 

RFCI RFC Indicator 

RNL Radio Network Layer 

SAP Service Access Point 

SDU Service Data Unit 

SMpSDU Support Mode for predefined SDU size 

SRNC Serving RNC 

SRNS Serving RNS 

SSSAR Service Specific Segmentation And Reassembly 

TFI Transport Format Identification 

TFO Tandem Free Operation 

TNL Transport Network Layer 

TrFO Transcoder Free Operation 

TrM Transparent Mode 

UP User Plane 

UUI User to User Information 

3.3 Concepts 

lu UP mode of operation: 

One objective of the lu User Plane (UP) protocol is to remain independent of the CN domain (Circuit Switched or 
Packet Switched) and to have limited or no dependency with the Transport Network Layer. Meeting this objective 
provides the flexibility to evolve services regardless of the CN domain and to migrate services across CN domains. 

The lu UP protocol is therefore defined with modes of operation that can be activated on a RAB basis rather than on a 
CN domain basis or (tele)service basis. The lu UP mode of operation determines if and which set of features shall be 
provided to meet e.g. the RAB QoS requirements. 

lu UP protocol PDU Type: 

The lu UP protocol PDU Types are defined for a given lu UP mode of operation. An lu UP PDU Type represents a 
defined structure of an lu UP protocol frame. For instance, a frame made of a certain Frame Header mask part and a 
Frame Payload part would be specified as a certain PDU type valid for a given lu UP mode of operation. 

Tandem Free Operation (TFO): 

Configuration of a Speech or Multimedia call for which Transcoders are physically present in the communication path 
but transcoding functions are disabled or partially disabled. The Transcoders may perform control and/or protocol 
conversion functions. 

Transcoder (TC): 

Physical device present in the network responsible for the transcoding of the speech data between two speech codecs or 
coding schemes (The Transcoder may also include other functions, i.e. Rate Adaptation in GSM). 

Transcoder Free Operation (TrFO): 

Configuration of a Speech or Multimedia call for which Transcoders are not present in the communication path. 



4 General 

4.1 General aspects 

The lu UP protocol is located in the User plane of the Radio Network layer over the lu interface: the lu UP protocol 
layer. 

The lu UP protocol is used to convey user data associated to Radio Access Bearers. 
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One lu UP protocol instance is associated to one RAB and one RAB only. If several RABs are established towards one 
given UE, then these RABs make use of several lu UP protocol instances. 

lu UP protocol instances exist at lu access point as defined [2] i.e. at CN and UTRAN. Whenever a RAB requires 
transfer of user data in the lu UP, an lu UP protocol instance exists at each lu interface access points. These lu UP 
protocol instances are established, relocated and release together with the associated RAB. 

Whether these peer protocol instances perform some RAB related function depends on the mode of operation of the lu 
UP as defined below. 

The following figure illustrates the logical placement of the lu UP protocol layer and the placement of the Data Streams 
sources outside of the Access Stratum. 
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Figure 1 : lu UP protocol layer occurrence in UTRAN overall architecture (User Plane View) 

4.2 Operational and Functional aspects 

4.2.1 lu UP protocol modes of operation 

The lu UP protocol operates in mode according to the concept described in earlier section. 
Modes of operation of the protocol are defined: 

1) Transparent mode (TrM) 

2) Support mode for predefined SDU size (SMpSDU) 

Determination of the lu UP protocol instance mode of operation is a CN decision taken at RAB establishment based on 
e.g. the RAB characteristics. It is signalled in the Radio Network layer control plane at RAB assignment and relocation 
for each RAB. It is internally indicated to the lu UP protocol layer at user plane establishment. 

The choice of a mode is bound to the nature of the associated RAB and cannot be changed unless the RAB is changed. 

4.2.2 Transparent mode (TrM) 

The transparent mode is intended for those RABs that do not require any particular feature from the lu UP protocol 
other than transfer of user data. 

The following figure illustrates the transparent mode of operation of the lu UP protocol layer: 
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Figure 2: lu UP protocol layer in transparent occurrence over lu interface 

In this mode, the lu UP protocol instance does not perform any lu UP protocol information exchange with its peer over 
the lu interface: no lu frame is sent. The lu UP protocol layer is crossed through by PDUs being exchanged between 
upper layers and transport network layer. 

For instance, the transfer of GTP-U PDUs could utilise the transparent mode of the lu UP protocol. 

4.2.3 Support mode 

The support modes are intended for those RABs that do require particular features from the lu UP protocol in addition 
to transfer of user data. When operating in a support mode, the peer lu UP protocol instances exchange lu UP frames 
whereas in transparent mode, no lu UP frames are generated. 

The following figure illustrates the functional model of the lu UP protocol layer in support mode of operation: 




Figure 3: lu UP protocol layer in support mode occurrence over lu interface 
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Some RABs requesting lu UP protocol support, constrain the lu UP protocol and possibly the radio interface protocols 
in specific ways. For instance, certain RABs can have variable predefined rates. 

The lu UP support mode is prepared to support variations. 

The only support mode defined here is the: 

Support mode for predefined SDU size (SMpSDU). 

For instance, the transfer of AMR speech PDUs would utilise the support mode for predefined SDU size of the lu UP 
protocol because it requires some procedure control functions and some data streams specific functions while the sizes 
of the user data being transferred can vary in a predefined manner. 

5 Transparent mode 

5.1 General 

5.1 .1 Operation of the lu UP in Transparent mode 

The lu UP layer in Transparent mode is present in the lu User plane for transferring data transparently over the lu 
interface. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

5.1 .2 Interfaces of the lu UP protocol layer in Transparent mode 

Interfaces of the lu UP protocol layer in transparent mode are the transport network layer and the upper layers. The lu 
UP protocol layer in Transparent Mode is an empty layer through which NAS Data Streams PDUs are crossing between 
the Transport Network Layer and upper layers. 

The lu UP protocol layer in transparent mode is using services of the Transport layers in order to transfer the lu UP 
PDUs over the lu interface. 

5.2 lu UP Protocol layer Services in Transparent mode 

The following functions are needed to support this mode: 
Transfer of user data. 

5.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in Transparent mode expects the following services from the Transport Network Layer: 
- Transfer of user data. 

5.4 Elements for lu UP communication in Transparent mode 
5.4.1 Frame Format for transparent mode 

The following shows the format of the PDU crossing the lu UP protocol layer in transparent mode. This frame is 
transferred transparently between the lu UP protocol upper layers and transport network layer (TNL-SAP). 
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Figure 4: Frame format for transparent mode 

This PDU has a variable length of n octets, whose maximum range depends on the type of user data (e.g. IP packet, Non 
Transparent CS data etc.). No explicit length indication is visible at the lu UP protocol layer. 



Support mode 



6.1 



General 



6.1 .1 Operation of the lu UP in Support mode 

The lu UP protocol layer in Support mode is present for data streams that need frame handling in the UP. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

6.1 .2 Interfaces of the lu UP protocol layer in Support mode 

As part of the Access Stratum responsibility, the lu UP protocol layer in support mode provides the services and 
functions that are necessary to handle non access stratum data streams. The lu UP protocol layer in support mode is 
providing these services to the UP upper layers through a Dedicated Service Access Point used for Information Transfer 
as specified in [5]. 

The lu UP protocol layer in support mode is using services of the Transport layers in order to transfer the lu UP PDUs 
over the lu interface. 

6.2 lu UP Protocol layer Services in Support mode 

Support mode for predefined SDU size Service 

The following functions are needed to support this mode: 
Transfer of user data; 
Initialisation; 
Rate Control; 
Time Alignment (FFS); 
Handling of error event; 
Frame Quality Classification. 
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6.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer expects the following services from the Transport Network Layer: 
Transfer of user data. 



6.4 

6.4.1 



Functions of the lu UP Protocol Layer in Support mode 
Functional model of the lu UP Protocol Layer in Support mode 
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Figure 5: Functional model of the lu UP protocol layer in Support mode 

The lu UP protocol layer in Support mode is made of three sets of functions: 

1 ) Frame Handler function 

2) Procedure Control functions 

3) Non Access Stratum Data Streams specific functions. 

6.4.2 Frame Handler function 

This function is responsible for framing and de-framing the different parts of an lu UP protocol frame. This function 
takes the different parts of the lu UP protocol frame and set the control part field to the correct values. It also ensures 
that the frame control part is semantically correct. This function is responsible for interacting with the Transport layers. 
This function is also responsible for the CRC check of the lu UP frame header. The lu UP frame with header CRC 
check error is discarded. 

6.4.3 Procedure Control functions 

This set of functions offers the control of a number of procedures handled at the lu UP protocol level. These functions 
are responsible for the procedure control part of the lu UP frames. 

Namely, these procedures are: 

Rate Control: is the procedure which controls over the lu UP the set of permitted rates among the rates that can 
be controled. The set of rates is represented by RFCI indicators and (when applicable) downlink send intervals. 
The function controlling this procedure interacts with functions outside of the lu UP protocol layer. 
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Initialisation: is the procedure which controls the exchange of initialisation information that is required for 
operation in support mode for predefined SDU size. Such information can contain the RFCI Set to be used until 
termination of the connection or until the next initialisation procedure. 

Time Alignment (FFS): is the procedure that controls the information exchanged over the lu related to the 
sending time of lu UP frames. The function controlling this procedure interacts with functions outside of the lu 
UP protocol layer. 

Handling of Error Event: is the procedure that controls the information exchanged over the lu related to 
detection of a fault situation. The function controlling this procedure interacts with functions outside of the lu 
UP protocol layer. 

6.4.4 Non Access Stratum Data Streams specific function(s) 

These functions are responsible for a "limited manipulation" of the payload and the consistency check of the frame 
number. If a frame loss is detected due a gap in the sequence of the received frame numbers, this shall be reported to the 
procedure control function. These functions are responsible for the CRC check and calculation of the lu UP frame 
payload part. These functions are also responsible for the Frame Quality Classification handling as described below. 

These functions interact with the upper layers by exchanging lu data stream blocks of lu UP frame payload. These 
functions also handles the padding and depadding of the lu UP frame payloads when needed. 

These functions interact with the procedure control functions. 

These functions provide service access to the upper layers for the procedure control functions. 



6.4.4.1 



Frame Quality Classification function 



6.4.4.1.1 



General 



On the lu UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is 
based on the radio frame classification and the setting of the RAB attributes 'Delivery of erroneous SDUs'. The RAB 
attribute 'Delivery of erroneous SDUs' tells if erroneous frames shall be delivered or not. 

Figure 6 below shows the main input and output information for frame quality classification function on the lu UP. 



UTRAN 



lu Interface 



RNL-SAP 



Frame from 
source codi^i 
device 



CN 



Won Access 
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Access Stratum 



Frame Quality 
Classification 
Result of 
FQC AIMD CRC 
resuits 




Figure 6: Frame quality classification in lu UP 
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6.4.4.1.2 



Handling of FQC information 



In SRNC on the sending side, the Support Mode Functions takes as input the radio frame quality information together 
with the frame. Based on this, the FQC is set ftir the frame, a CRC is added, if needed and the frame is sent to CN. The 
following table is shows the FQC field setting: 



INPUT 


ACTION 


Delivery of 
erroneous SDUs 


Radio Frame 
Classification 


Action taken in SRNC 
on the sending side 


Yes 


Bad 


Set FQC to 'bad radio' 


No 


Bad 


Drop frame 


Not Applicable 


Any value 


Set FQC to good 


Any value 


Good 


Set FQC to good 



The Support Mode Functions in CN on the receiving side makes a CRC check of the frame payload, if CRC is present 
and passes the frame and the frame quality classification information through the RNL-SAP. 



INPUT 


ACTION 


Delivery of 
erroneous SDUs 


Payload CRC 
check result 


Actions taken at CN on 
the receiving side 


Yes 


Not OK 


Frame forwarded with 
FQC set to 'bad' 


No 


Not OK 


Drop frame, send lu-UP- 
Status primitive 
indicating 'No data' at the 
RNL-SAP 


Not Applicable 


Any result 


Frame forwarded with 
FQC as set by UTRAN 


Any value 


OK 


Frame forwarded with 
FOG as set by UTRAN 



The Support Mode Functions in CN on the sending side adds a CRC, if necessary to the frame payload and passes it 
together with the FQC (in the transcoded case always set to good). 

The Support Mode Functions in SRNC then makes a CRC -check, if CRC present. Based on the received FQC and 
eventually the CRC check, decision is made whether to deliver the frame or not. 



INPUT 


ACTION 


Delivery of 
erroneous SDUs 


FQC 


CRC check 
(if payload 

CRC 
present) 


Actions taken at 
SRNC on the 
receiving side 


Yes 


Bad 


Any result 


Drop frame 


No 


Bad 


Any result 


Drop frame 


Yes 


Bad 
radio 


Any result 


Drop frame 


No 


Bad 
radio 


Any result 


Drop frame 


Yes 


Any 
value 


Not OK 


Drop frame 


No 


Any 
value 


Not OK 


Drop frame 


N/A 


Any 
value 


Any result 


Pass the frame to 
radio interface 
protocols 


Any value 


Good 


OK 


Pass the frame to 
radio interface 
protocols 



NOTE: The case where SRNC receives a frame with the FQC set to to "bad radio" (respectively: "bad"), 

corresponds to a TrFO (respectively: TFO) case. The frame is then trashed by the receiving RNC since 
there is currently no means to pass down to the UE the frame quality indicator. 
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6.5 Elementary procedures 
6.5.1 Transfer of User Data procedure 



6.5.1.1 



Successful operation 



The purpose of the transfer of user data procedure is to transfer lu UP frames between the two lu UP protocol layers at 
both ends of the lu interface. Since an lu UP instance is associated to a RAB and a RAB only, the user data being 
transferred only relate to the associated RAB. 

The procedure is controlled at both ends of the lu UP instance i.e. SRNC and the CN. 

The transfer of user data procedure is invoked whenever user data for that particular RAB needs to be sent across the lu 
interface. 

The procedure is invoked by the lu UP upper layers upon reception of the upper layer PDU and associated control 
information: RFCI. 

In SRNC, the upper layers may deliver a frame quality classification information together with the RFCI. 

The NAS Data streams functions makes the padding of the payload (if needed) so that the lu UP frame payload will be 
an integer number of octets. Then the NAS Data streams functions perform, if needed, CRC calculation of the lu frame 
payload and passes the lu UP frame payload down to the frame handler together with the RFCI. 

The frame handler function retrieves the frame number from its internal memory, format the frame header and frame 
payload into the appropriate PDU Type and sends the lu UP frame PDU to the lower layers for transfer across the lu 
interface. 

Upon reception of a user data frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

The Frame handler checks the consistency of the frame header. If correct, the frame handler stores the frame 
number and passes the lu UP frame payload and associated CRC, if any to the NAS Data Streams functions. The 
received RFCI is passed to the Procedure Control Function. 

The NAS Data Streams functions check the payload CRC, if any. If the RFCI is correct and matches the lu UP 
frame payload as indicated by the Procedure Control functions, the NAS Data Streams removes the padding bits 
from the lu UP frame payload based on the RFCI information. Then the NAS Data Streams forwards to the 
upper layers the RFCI and the payload. 



RNC/ 



CN 



Transfer of User Data 
(RFCI, payload) 



CN/ 
RNC 



Figure 7. Successful Transfers of User Data 



6.5.1.2 



Unsuccessful operation 



If the lu UP frame carrying the user data is incorrectly formatted or cannot be correctly treated by the receiving lu UP 
protocol layer, the lu UP protocol layer shall either discard the frame or pass it to the upper layers with a frame 
classification indicating a corrupted frame. This decision is based on configuration data of the lu UP instance for that 
particular RAB (i.e. if the RAB requests delivery of corrupted frame). 

If the lu UP protocol layer detects a frame loss because of a gap in the received frame number sequence while the frame 
number does not relate to time (see section Time Alignment), the receiving lu UP protocol layer shall report this to the 
procedure control function. 
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RNC/ 
CN 



Transfer of User Data 
(RFCI, payload) 



CN/ 
RNC 




Figure 8. Unsuccessful Transfers of User Data: 1) Corrupted Frame, 2) Detection of Frame loss 

6.5.2 Initialisation procedure 



6.5.2.1 



Successful operation 



This procedure is mandatory for RABs using the support mode for predefined SDU size. The purpose of the 
initialisation procedure is to configure both termination points of the lu UP with the RFCIs and associated RAB Sub 
Flows SDU sizes necessary during the transfer of user data phase. Additional parameters may also be passed. 

The initialisation procedure is always controlled by the entity in charge of establishing the Radio Network Layer User 
Plane i.e. SRNC. 

The initialisation procedure is invoked whenever indicated by the lu UP Procedure Control function e.g. as a result of a 
relocation of SRNS or at RAB establishment over lu. 

When this procedure is invoked all other lu UP procedures are suspended until termination of the initialisation 
procedure. 

The SRNC allocates a RAB sub-Flow Combination indicator (RFCI) to each RAB sub-Flow Combination. The 
association of indicators to RAB Flow Combinations is valid in the lu UP until a new initialisation procedure is 
performed or the connection is terminated. 

The procedure control function may also generate additional lu UP protocol parameters necessary for the RAB service 
to operate properly over lu. 

To each RAB sub-Flow combination indicator is associated the size of each RAB sub-Flow SDU of that combination. 
The list of RAB Flow Combination Indicators and their respective SDU sizes constitutes the RAB sub-Flow 
Combination set passed over the lu UP in the initialisation frame i.e. into an appropriate lu UP PDU Type. 

The first RAB sub-Flow Combination proposed in the list of RAB sub-Flow Combination indicates the initial RAB sub- 
Flow Combination i.e. the first RAB sub-Flow Combination to be used when starting the communication phase i.e. the 
transfer of user data procedure. 

The complete set of information is framed by the lu UP Frame Handler function and transferred in an lu UP 
initialisation frame. If needed, the initialisation frame CRC is calculated and set accordingly in the respective frame 
field. 

A supervision timer T j^ix is started after sending the lu UP initialisation frame. This timer supervises the reception of 
the initialisation acknowledgement frame. 

Upon reception of a frame indicating that an initialisation control procedure is active in the peer lu UP entity, the lu UP 
protocol layer forwards to the upper layers the RAB sub-Flow Combination set to be used by the Control procedure 
function. It also stores the RAB sub-Flow Combination set in order to control during the transfer of user data, that the lu 
UP payload is correctly formatted (e.g. RFCI matches the expected lu UP frame payload total length). 

If the initialisation frame is correctly formatted and treated by the receiving lu UP protocol layer, this latter sends an 
initialisation acknowledgement frame. 

Upon reception of an initialisation acknowledgement frame, the lu UP protocol layer in the SRNC stops the supervision 
timer T jnit. 
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If the initialisation procedure requires that several frames are to be sent, each frame shall be acknowledged individually. 

If several initialisation frames are used for the initialisation procedure, the next frame shall wait for the 
acknowledgement of the previous frame to be received before sending. The supervision timer is used individually for 
each frame in a chain. 

The frame number is always set to zero for the first frame in a chain and it shall be incremented in the sending direction 
for each sent frame. The acknowledgement or negative acknowledgement carries the frame number of the frame being 
acknowledged. 

Upon reception of an initialisation negative acknowledgement frame or at timer T i^n- expiry, the lu UP protocol layer 
in the SRNC shall reset and restart the T iNn- supervision timer and repeat an initialisation frame. The repetition can be 
performed n times, n being chosen by the operator (default n=3). 

Consequently, when in the communication phase (as indicated by internal functions in the Radio Network layer), the 
frame transmission starts in downlink in the initial RFCI. 

In the case where an SRNC receives an lu frame indicating that an initialisation procedure is active at the other end of 
the lu UP, RFCI is applied as follows: 

- For the sending frame, i.e. UL direction, RNC uses the RAB sub-Flows Combination set indicated in 
Initialisation phase of the peer TFO or TrFO partner. 

For the receiving frame, i.e. DL direction, RNC uses the RAB sub-Flows Combination set as sent in its own 
initialisation frame. 



RNC 



^ 



Transfer Of User Data 
* it can repeated n times 



CN/ 

Initialisation other 

((RFCI, SDU sizes)J ~ 



Initialisation ACK 



Figure 9: Successful Initialisation of lu UP for m RFCIs 



6.5.2.2 



Unsuccessful operation 



If the initialisation frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer, 
this latter sends an initialisation negative acknowledgement frame. 

If after n repetition, the initialisation procedure is unsuccessfully terminated (because of n negative acknowledgement 
or timer T init expires), the lu UP protocol layers (sending and receiving) take appropriate local actions. 



RNC 



1 



2) 



V 



Initialisation 
((RFCI, SDU sizes)J 

Initialisation NACK 



* after n repetitions 



CN/ 
other 



Figure 10: Unsuccessful initialisation of lu UP: 1) n negative acknowledgement or 2) n timer expires 

NOTE: The case where an SRNC receives an lu frame indicating that an initialisation procedure is active at the 
other end of the lu UP could be related to a TFO or TrFO negotiation. How TFO or TrFO protocol and 
codec negotiation is performed is FFS. 
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6.5.3 lu Rate Control procedure 



6.5.3.1 



Successful operation 



The purpose of the rate control procedure is to signal to the peer lu UP protocol layer the permitted rate(s) over lu in the 
reverse direction of the sent rate control frame. 

The rate control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN i.e. 
SRNC. In some cases, as TrFO and TFO, it is also controlled by the remote partner at the other end of the lu UP. 

The lu rate control procedure is invoked whenever the SRNC decides that the set of downlink permitted rates over lu 
shall be modified. This set can be made of only one permitted rate among the rates that are permitted for rate control or 
several rates among the rates that can be rate controlled by the SRNC. 

The rates that can be controlled by the SRNC are indicated to the lu UP at establishment in addition to the rates that 
cannot be controlled by the RNC e.g. such as DTX rates for certain RABs. 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 

The Procedure control function upon request of upper layer prepares the Rate control frame payload containing the 
permitted rates of the reverse direction of the rate control frame. The permitted rate is given as RFCI indicators and 
(when applicable) the downlink send intervals. 

The frame handler function calculates the frame CRC, formats the frame header into the appropriate PDU Type and 
sends the lu UP frame PDU to the lower layers for transfer across the lu interface. 

Upon reception of a rate control frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

The Frame handler checks the consistency of the frame header and associated CRC. If correct, the frame handler 
passes procedure control part to the procedure control functions. 

The procedure control functions check that the new permitted rate(s) are consistent with the RFCI set received at 
initialisation. They also verify that non-rate controllable rates are still permitted. If the whole rate control 
information is correct, the procedure control functions passes the rate control information to the NAS Data 
Streams specific functions. 

The NAS data streams specific functions forward to the upper layers the rate control information in a lu-UP- 
Status indication primitive. 
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Figure 11 : Successful Rate Control sent from SRNC 
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CN 



RNC 



Rate Control 

(RFCI indicators, 

[Downlink send intervals*]) 



*Optional 



Figure 12: Successful Rate Control sent from CN 



6.5.3.2 



Unsuccessful operation 



If the lu UP in the SRNC detects that the rate control command has not been correctly interpreted or received (e.g. the 
rate is outside the set of permitted rates in the reverse direction of the rate control frame), the lu UP shall retrigger a rate 
control procedure. If after "m" repetitions, the error situation persists, the lu UP protocol layers (sending and receiving) 
take the appropriate local actions. 

If the lu UP protocol layer receives a rate control frame that is badly formatted or corrupted, it shall ignore the rate 
control frame. 
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Figure 13: Unsuccessful Transfers of rate control from RNC: 1) Frame loss 2) Corrupted Frame 
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Figure 14: Unsuccessful Transfers of rate control from CN: 1) Frame loss 2) Corrupted Frame 

6.5.4 Time Alignment procedure (FFS) 
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6.5.5 Handling of Error Event procedure 



6.5.5.1 



Successful operation 



The purpose of the Error event procedure handles the error reporting. Over the lu UP protocol the error reports are made 
with Error event frames. The Error event procedure in the lu UP can be triggered by: 

an error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with unknown 
or unexpected data). In this case an lu UP- Status Indication may be used to inform the upper layers. 

a request by the upper layers 

When an Error event is reported by an Error event frame the following information shall be included: 

A cause value. 

Error distance (=0 if lu UP function detected, =1 if requested by upper layers). 

Upon reception of an Error report frame the lu UP functions should take appropriate local actions based on the cause 
value. This may include to report the error to the upper layers with an lu UP status indication. 



RNC/ 

CN or other 



Error event 
(Cause value, 
Error distance) 



CN or other/ 



RNC 



Figure 15: Successful Error event 



6.5.5.2 



Unsuccessful operation 



If the error event frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer 
appropriate local actions are taken (e.g. upper layers are informed). An error in an Error event frame should not 
generate the sending of an ne Error event frame. 
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Figure 16: Unsuccessful Transfers of Error event frame: 1) Frame loss 2) Corrupted Frame 



ETSI 



(3G TS 25 415 version 3.1.0 Release 1999) 



23 



ETSI TS 125 415 V3.1.0 (2000-01) 



6.5.6 Frame Quality Classification 

The Frame Quality Classification procedure uses the services of the Transfer of User Data procedure to exchange across 
the lu UP interface the Frame Quality Classification information. 

rRNO 



CN Transfer of User Data 
(FQC, RFCI, payload) 

Transfer of User Data 
(FQC, RFCI, payload) 



CN/ 
RNC 



Figure 17: Successful Transfers of User Data with FQC information 

6.6 Elements for lu UP communication in Support mode 
6.6.1 General 

In this specification the structure of frames will be specified by using figures similar to Figure 18 below. 



Bits 


-z. 

en -^ 
O 






7 


6 


5 


4 


3 


2 


1 







Field 1 


Field 2 


1 


Octet 1 


Header 
part 


Field 3 


Field 4 


2 


Octet 2 
Octet 3 


Field 4 continue 


Spare 


Field 6 


2 


Octet 4 
Octet 5 


Payload 
part 


Field 6 continue 


Padding 



Figure 18: Example frame format 

Unless otherwise indicated, fields which consist of multiple bits within a octet will have the more significant bit located 
at the higher bit position (indicated above frame in Figure 18). In addition, if a field spans several octets, more 
significant bits will be located in lower numbered octets (right of frame in Figure 18). 

On the lu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits 
are sent according decreasing bit position (bit position 7 first). 

Spare bits should be set to by the sender and should not be checked by the receiver. 

The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding 
'Padding' when needed). 
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6.6.2 Frame Format for predefined size SDUs 



6.6.2.1 



PDU Type 



PDU Type is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes. Error detection 
scheme is provided over the lu UP for the payload part. 

The following shows the lu frame structure for PDU type of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP): 



Bits 


So 

o 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=0) 


Frame Number 


1 


Frame 

Control 

Part 


FQC 


RFCI 


1 


Header CRC 


Payload CRC 


2 


Frame 
Check 
Sum Part 


Payload CRC 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 



Figure 19: lu UP PDU Type Format 

The lu UP PDU Type is made of three parts: 

1) lu UP Frame Control part (fixed size) 

2) lu UP Frame Check Sum part (fixed size) 

3) lu UP Frame Payload part (pre-defined SDU sizes) 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type Frame Header. 

6.6.2.2 PDU Type 1 

PDU Type 1 is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes when no payload 
error detection scheme is necessary over lu UP (i.e. no payload CRC). 

The following shows the lu frame structure for PDU type 1 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP): 
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Bits 


2. 3- 
o 




7 


6 


5 


4 


3 


2 


1 







PDUType(=1) 


Frame Number 


1 


Frame 

Control 

Part 


FQC 


RFCI 


1 


Header CRC 


Spare 


1 


Frame 
Check 
Sum Part 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 



Figure 20: lu UP PDU Type 1 Format 

The lu UP PDU Type 1 is made of three parts: 

1) lu UP Frame Control part (fixed size) 

2) lu UP Frame Check Sum part (fixed size) 

3) lu UP Frame Payload part (pre-defmed SDU sizes) 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 1 Frame Header. 



6.6.2.3 



PDU Type 14 



6.6.2.3.1 



General 



PDU Type 14 is defined to perform control procedures over the lu UP in support mode for pre-defined SDU sizes. The 
control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to 
the control procedure. 

Figure 21 below shows the lu frame structure for PDU Type 14 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP): 
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Bits 


-z. 
o 3 

en -^ 
O 




7 


6 


5 


4 


3 


2 


1 









PDUType(=14) 


Ack/Nack (=0, 
i.e. procedure) 


PDUType14 
Frame Number 


1 


Frame 

Control 

Part 


Procedure Indicator 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 

m Part 


Payload CRC 


1 




Reserved for procedure data 


0-n 


Frame 

payload 

part 



Figure 21 : lu UP PDU Type 14 Format for procedure sending 

The lu UP PDU Type 14 is made of three parts: 

1) lu UP Frame Control part (fixed size) 

2) lu UP Frame Check Sum part (fixed size) 

3) lu UP Frame Payload part (variable length, rounded up to octet) 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header. 

6.6.2.3.2 Positive Acknowledgement 

When the PDU Type 14 is used to positively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP: 



Bits 


en -^ 
O 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack (=1, 
i.e. Ack) 


PDU Type 14 
Frame Number 


1 


Frame 

Control 

Part 


Procedure Indicator 
(indicating the procedure being positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 



Figure 22: lu UP PDU Type 14 Format for positive acknowledgement 

The lu UP PDU Type 14 for positive acknowledgment is made of two parts: 
1) lu UP Frame Control part (fixed size) 
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2) lu UP Frame Check Sum part (fixed size) 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
positive acknowledgement. 



6.6.2.3.3 



Negative Acknowledgement 



When the PDU Type 14 is used to negatively acknowledge a control procedure, the PDU Type 14 fi^ame takes the 
following structure at the TNL-SAP: 



Bits 


"1 

CO -> 

o 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack (=2, 
i.e. Nack) 


PDU Type 14 
Frame Number 


1 


Frame 

Control 

Part 


Procedure Indicator 
(indicating the procedure being negatively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Error Cause value 


Spare 


1 


Frame 

payload 

part 



Figure 23: lu UP PDU Type 14 Format for negative acknowledgement 

The lu UP PDU Type 14 for negative acknowledgment is made of three parts: 

1) lu UP Frame Control part (fixed size) 

2) lu UP Frame Check Sum part (fixed size) 

3) lu UP Frame Payload part (fixed size) 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
negative acknowledgement. 



6.6.2.3.4 



Procedures Coding 



6.6.2.3.4.1 Initialisation 

The figure below specifies how the initialisation procedure frame is coded. 
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Bits 


-z. 
o 3 

cn -^ 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0. 
I.e. Procedure) 


PDUTypeM 
Frame Number 


1 


Frame 

Control 

Part 


Procedure Indicator (=0) 


1 


Header CRC 


Payload CRC 


2 


Frame 

Checksum 

part 


Payload CRC 


Spare 


Number of subflows per 
RFCI (N) 


Chain 
Ind 


1 


Frame 

payload 

part 


Spare 


LI 


1"RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-1)x{1 
or 2) 


Spare 


LI 


2"^* RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-1)x{1 
or 2) 







Figure 24: lu UP PDU Type 14 used for Initialisation 



6.6.2.3.4.2 



Rate Control 



The Figure below specifies how the rate control procedure frame is coded when the rate control uses only RFCI 
indicators. 
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Bits 




-z. 
o 3 

en -^ 
O 






















7 


6 


5 


4 


3 


2 


1 











PDUType(=14) 


Ack/Nack (=0, 


PDUType14 


1 


Frame 






i.e. Procedure) 


Frame Number 




Control 
Part 


Procedure Indicator (=1) 


1 






Payload CRC 


1 


Frame 
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Figure 25: lu UP PDU Type 14 Format used for Rate Control 

The Figure below specifies how the rate control procedure is coded when both RFCI indicators and Downlink send 
intervals are used. 
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Figure 26: lu UP PDU Type 14 Format used for Rate Control 



6.6.2.3.4.3 



Time Alignment (FFS) 



6.6.2.3.4.4 Error Event 

The Figure below specifies how the Error Event procedure is coded. 
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Figure 27: lu UP PDU Type 14 Format used for Error Event 



6.6.3 Coding of information elements in frames 



6.6.3.1 



PDU Type 



Description: The PDU type indicates the structure of the lu UP frame. The field takes the value of the PDU Type it 
identifies: i.e. for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. 

Value range: {0-14, 15=reserved for future PDU type extensions} 

Field length: 4 bits 



6.6.3.2 



Ack/Nack 



Description: The Ack/Nack field tells if the frame is: 

• a control procedure frame 

• a positive acknowledgement (ACK) of a control procedure frame 

• a negative acknowledgement (NACK) of a control procedure frame. 

Value range: {O=control procedure frame, 1=ACK, 2=NACK, 3=reserved} 
Field length: 2 bits 



6.6.3.3 



Frame Number 



Description: The lu UP frame numbering is handled by a Frame Number. The purpose of the Frame Number is to 
provide the receiving entity with a mechanism to keep track of lost lu UP frames. For a given user data connection, 
there is no relations between the frame numbers of frames sent in the downlink direction and the frame numbers of 
frames sent in the uplink direction. 

Value range: {0-15} 

Field length: 4 bits 



6.6.3.4 



PDU Type 14 Frame Number 



Description: The lu UP frame numbering is handled by a Frame Number. The purpose of the PDU Type 14 Frame 
Number is to provide the receiving entity with a mechanism to keep track of lost lu UP frames.It is also used to relate 
the acknowledgment frame to the frame being acknowledged i.e. the same PDU Type 14 Frame Number is used in the 



ETSI 



(3G TS 25 41 5 version 3.1 .0 Release 1 999) 32 ETSI TS 1 25 41 5 V3.1 .0 (2000-01 ) 

acknowledgement frame as the one used in the frame being acknowledged. 
Value range: {0-3} 
Field length: 2 bits 

6.6.3.5 Frame Quality Classification (FQC) 

Description: Frame Quality Classification is used to classify the lu UP frames depending on whether errors have 
occurred in the frame or not. Frame Quality Classification is dependent on the RAB attribute 'Delivery of erroneous 
SDUs'. 

Value range: {0=frame good, l=frame bad, 2=Frame bad due to radio, 3=spare} 

Field length: 2 bits 

6.6.3.6 RAB sub-Flow Combination Indicator (RFCI) 

Description: The RFCI identifies the structure of the payload. This can be used to specify the sizes of the subflows. 
Value range: {0-62, 63=RFCI not applicable} 
Field length: 6 bits 

6.6.3.7 Procedure Indicator 

Description: The Procedure Indicator identifies the control procedure in the current frame. 

Value range: {O=initialization, l=rate control, 2=time alignment, 3=abnormal event, 4-255=reserved} 

Field length: 8 bits 

6.6.3.8 Header CRC 

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the 
generator polynom G(D) = D''H-D^H-D^H-D^H-D'H-l.With this CRC all error bursts shorter than 7 bits are detected, as well 
as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, (max 3 octets). 

Field length: 6 bits 

6.6.3.9 Payload CRC 

Description: This field contains the CRC of all the fields (including Padding) of the Frame Payload. The CRC is a 10- 
bit checksum based on the generator polynom G(D) = D'V D'H-D^H-D''H-D'H-l.With this CRC all error bursts shorter 
than 1 1 bits are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter 
than 500 bits (max 62 octets). 

Field length: 10 bits 

6.6.3.10 Chain Indicator 

Description: Chain indicator is used to indicate whether the control procedure frame is the last frame related to the 
control procedure. 

Value range: {0=this frame is the last frame for the procedure, l=additional frames will be sent for the procedure} 

Field length: 1 bit 

6.6.3.11 Number of Subflows per RFCI 

Description: Number of Subflows per RFCI field indicates the number of subflows the RAB is made of It is used to 
decode the SDU size information data lengths. All RFCs consist of the same number of subflows within a specific 
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RAB. 

Value range: {0=reserved, 1-7} 

Field length: 3 bits 

6.6.3.1 2 Length Indicator (LI) 

Description: Length Indicator, indicates if 1 or 2 octets is used for the RAB subflow size information. 
Value range: {O=one octet used, l=two octets used} 
Field length: 1 bit 

6.6.3.1 3 Number of RFCI Indicators 

Description: Number of RFCI indicators indicates the number of RFCI indicators present in the control procedure 
frame. 

Value range: {0-63} 

Field length: 6 bits 

6.6.3.14 RFCI n Indicator 

Description: RFCI n Indicator points to an RFCI number e.g. RFCI Indicator points to RFCI 0, RFCI 1 Indicator 
points to RFCI 1 , etc . . . 

Value range: {0=RFCI allowed, 1=RFCI barred} 

Field length: 1 bit 

6.6.3.15 Error distance 

Description: Indicates if the error occurred at the error reporting entity (=0) or in a more distant entity. The error 
distance is incremented by one (or kept at its maximum value) when an error report is forwarded. 

0: Reporting local error 
1 : First forwarding of error event report 
2: Second forwarding of error event report 
3: Reserved for future use 

Value range: {0: Reporting local error, 1: First forwarding of error event report. 2: Second forwarding of error event, 3: 
Reserved for future use} 

Field length: 2 bit 

6.6.3.16 Error Cause value 

Description: Cause value is used to indicate what kind of error caused the error. 

0: CRC error of frame header 

1 : CRC error of frame payload 

2: Unexpected frame number 

3: Frame loss 

4: PDU type unknown 

5: Unknown procedure 

6: Unknown reserved value 

7: Unknown field 

8: Frame too short 

9: Missing fields 

10-15: spare 
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16: Unexpected PDU type 
18: Unexpected procedure 
19: Unexpected RFCI 
20: Unexpected value 
21^1: spare 

42: Initialisation failure 

43: Initialisation failure (timer expiry) 

44: Initialisation failure (repeated NACK) 

45: Rate control failure 

46: Error event failure 

47-63: spare 

Value range: {0-15 Used for syntactical protocol errors, 16-41 Used for semantical protocol errors, 42-63 Used for 
other errors } 

Field length: 6 bit 

6.6.3.1 7 Rate Control Type 

Description: Specifies the type of Rate control the current frame relates to. There are two types of Rate control: 
Rate control for fixed periodicity services. Only RFCI indicators present. 

Rate control for services with varying periodicity. RFCI indicators and Downlink send interval present. 

Value range: {0=Rate control using only RFCI indicators, l=Rate control including both RFCI indicators and 
Downlink send interval} 

Field length: 1 bit 

6.6.3.18 Downlink send interval 

Description: Specifies the Interval the downlink frames should be sent. 
Value range: {0=1 0ms, l=20ms, 2=40ms, 3-7= Spare} 
Field length: 3 bit 

6.6.3.19 Padding 

Description: This field is an additional field used to make the frame payload part an integer number of octets when 
needed. Padding is set to by the sender and is not interpreted by the receiver. 

Value range: {0-127} 

Field length: 0-7 bits 

6.6.4 Timers 



This Timer is used to supervise the reception of the initialisation acknowledgement frame from the peer lu UP instance. 
This Timer is set by O&M. 
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6.7 Handling of unknown, unforeseen and erroneous protocol 
data 

6.7.1 General 

Error handling in lu UP protocol is applicable only for lu UP in Support mode. 

The Error Event procedure is the procedure handling error reporting. The Error event procedure in the lu UP can be 
triggered by: 

an error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with unknown 

or unexpected data) 

a request by the upper layers 

an Error event frame over the lu UP protocol 

The error can be reported either by: 

an Error event frame over the lu UP protocol 

an lu UP Status Indication to upper layers (e.g. to be used by O&M) 

When an Error event is reported, either by an lu-UP-Status-Indication, or by an Error event frame the following 
information shall be included: 

Type of the error (syntactical error, semantical error or other error) 

- Error distance, i.e. information where the error occurred 

6.7.2 Error detected by lu UP functions 

When an error is detected within the lu UP functions (by receiving a frame containing erroneous, unknown or 
unexpected data) one of the following actions is taken depending on the type of the error 

1. Error indicated to upper layers by sending a lu-UP-Status-Indication primitive 

2. Error event frame sent 

3. Error event frame sent and error indicated to upper layers by sending a lu-UP-Status-Indication primitive 

4. No action 

6.7.3 Request by upper layers 

When the lU UP receives an lu-UP-Status-Request indicating Error event then an Error event frame should be sent over 
the lu UP protocol indicating the appropriate error type. 

6.7.4 Error event frame over the lu UP protocol 

When an Error event frame is received over the lu UP protocol an lu-Status-Indication with 'Error event' information 
indicating the error type should be made to the upper layers. The Error event report contains an 'Cause value' that tells 
the type of the error. The Error event report also contains a field 'Error distance' that tells the distance to the entity 
reporting the error event. The 'Error distance' is when the error is originally sent. When an Error event report is 
forwarded the 'Error distance' is incremented by one. 

6.7.5 Handling of error reports 
6.7.5.1 General 

The Figure 28 below shows the external error case when the error event procedure is originally triggered by an lu-UP- 
Status-Request. As an action on this the error event procedure sends an error event frame over the lu UP. On the other 
side the reception of error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to 
upper layers. The handling is symmetrical over the lu UP protocol. 
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Figure 28: External error 

The figure below shows the internal error case when the error event procedure is originally triggered by the lu UP 
functions. As an action on this the error event procedure sends an error event frame over the lu UP. On the other side 
the reception of error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to the upper 
layers. The handling is symmetrical over the lu UP protocol. 
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Figure 29: Internal error 
6.7.5.2 Error distance 

In an error event frame the error distance has the following meaning: 
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0: Error report relates to an lu UP function error at the other side 

1 : Error report relates to an error at the other side reported by the upper layers 

In an lu UP-Status indication the error distance has the following meaning: 

0: Error report relates to an local lu UP function error 

1 : Error report relates to an lu UP function error at the other side 

2: Error report relates to an error at the other side reported by the upper layers 

6.7.6 List of errors in lu UP 



Error Type 


Error Cause 


Recommended action 

by Error event 

procedure 


Possibly 

detected by 

function 


Comment 


Syntactical 


Bit error in Frame 
payload (CRC check) 


No action 


NAS data streams 
functions 


Handled by 
Frame Quality 
Classification, 
when applied 


Bit error in Frame Header 
(CRC check) 


lu-UP-Status- 
lndication(Error event) 


Frame handler 
functions 


Frame trashed 


Unexpected Frame 
Number 


lu-UP-Status- 
lndication(Error event) 


NAS data streams 
functions 




Frame loss 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


NAS data streams 
functions 




Unknown PDU type 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unknown procedure 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unknown or unexpected 
value 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Procedure control 
functions 




Frame too short 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




IVIissing fields 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Semantical 


Unexpected PDU type 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unexpected procedure 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unexpected RFCI 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


NAS data streams 
functions 




Unexpected value 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Procedure control 
functions 




Other error 


Initialisation failure 
(outside lu UP) 


Error event frame 


Function outside 
lu UP 




Initialisation failure 
(network error, timer 
expiry) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Initialisation failure (lu UP 
function error, repeated 
NACK) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Rate control failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Error event failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 
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7 Communication Primitives for the lu UP protocol 

layer 

7.1 Modelling Principle 

The principle illustrated by the figure below is used for modelling the primitives towards the protocol layer: 

REQUEST 




Figure 30: Modelling principle 



7.2 Primitives towards the upper layers at the RNL SAP 



7.2.1 



General 



The lu UP protocol layer interacts with upper layers as illustrated in the figure above. The interactions with the upper 
layers are shown in terms of primitives where the primitives represent the logical exchange of information and control 
between the upper layer and the lu UP protocol layer. They do not specify or constraint implementations. 

The following primitives are defined: 

- lu-UP-DATA 

- lu-UP-STATUS 

- lu-UP-UNIT-DATA 
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Table 1 : lu UP protocol layer service primitives towards the upper layer at the RNL SAP 



Primitive 


Type 


Parameters 


Comments 


lu-UP-DATA 


Request 


lu-UP-payload 




lu-UP-control 


RFCI 


Indication 


lu-UP-payload 




lu-UP-control 


RFCI 


FQC 


lu-UP-Status 


Indication 


lu-UP-Procedure-Control 


Error Cause, Error Distance 


Initialisation 


RFCI indicators, 

Downlink send intervals (when 

applicable) 


Time Alignment (FFS Note 1) 


Request 


lu-UP-Procedure-Control 


Error Cause 


RFCI indicators. 

Downlink send intervals (when 

applicable) 


lu-UP-UNIT- 
DATA 


Request 


lu-UP-payload 




Indication 


lu-UP-payload 





Primitive usage is function of the mode of operation of the lu UP protocol. The following table provides the association 
between lu UP primitives towards the upper layers and the lu UP mode of operation: 

Table 2: lu UP protocol layer service primitives related to the lu UP mode of operation and function 

within the mode of operation 



Primitive 


Type 


IWode of Operation 


lu-UP-DATA 

lu-UP-Status 

lu-UP-UNIT- 
DATA 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


TrM 


Indication 


TrM 



7.2.2 lu-UP-DATA-REQUEST 

This primitive is used as a request from the upper layer lu NAS Data Stream entity to send a RAB SDU on the 
established transport connection. This primitive also includes the RFCI of the payload information included in the 
primitive. 

The lu UP Frame protocol layer forms the lu UP data frame, the lu Data Stream DU being the payload of the lu UP 
frame, and transfers the frame by means of the lower layer services. 

7.2.3 lu-UP-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu NAS Data Stream User Plane information 
of a received lu UP frame. 

This primitive also includes the RFCI of the payload information included in the primitive. 
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At the RNL-S AP, this primitive may include an Frame Quality Classification indication. 

This primitive may also include information aiming at informing the upper layers of a faulty situation that relates to the 
payload included in the primitive. 

7.2.4 lu-UP-STATUS-REQUEST 

This primitive is used to pass down to the lu UP, the rate control information necessary for changing the permitted 
rate(s) in the reverse direction over lu. The rate control information consists of RFCI indicators and (when applicable) 
downlink send intervals. 

This primitive is also used to report that a fault has been detected. 

7.2.5 lu-UP-STATUS-INDICATION 

This primitive is used to report to the upper layer entity that a fault has been detected. The information concerning that 
fault is characterised by the Abnormal event information passed to the upper layer. 

This primitive is also used in the context of the initialisation control procedure to pass to the upper lu DS layer e.g. the 
RFC set and the associated RFCIs to be used in the communication phase. 

This primitive is used to indicate to the upper layers the set of permitted rate(s) in the reverse direction over lu. The set 
of permitted rate(s) is represented by RFCI indicators and (when applicable) downlink send intervals. 

This primitive is also used to indicate when a frame has been dropped as a result of frame quality classification 
handling. 

NOTE 1: Time Alignment is FFS. 

7.2.6 lu-UP-UNIT-DATA-REQUEST 

This primitive is used as a request from the upper layer to send an lu UP payload on the established transport 
connection. 

The lu UP protocol layer transfers the lu Data Stream DU by means of the lower layer services without adding any 
protocol header overhead. 

7.2.7 lu-UP-UNIT-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu UP payload. 

7.3 Primitives towards the transport layers at TNL SAP 
7.3.1 General 

Access to the Transport network Layer is performed through a generic SAP: TNL-SAP. 

When the Transport Network upper layer consists of AAL2, the TNL SAP maps onto the AAL-S AP through which 
communication is performed using specific AAL primitives. 

When the Transport Network upper layer consists of GTP-U, the TNL SAP maps onto the GTP-U SAP through which 
communication is performed using generic primitives. 

The choice of communication, specific or generic, through the TNL SAP is fixed by the Radio Network Layer control 
plane logic. This choice is based on the requirements placed by e.g. the RAB characteristics, the CN domain requesting 
the RAB establishment or other operator's choice. 
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7.3.2 ATM/AAL2 based Transport layer 



7.3.2.1 



General 



When the lu UP protocol layer uses the services of an ATM/AAL2 transport, it uses an established AAL2 connection 
for transferring frames between the peer TNL-SAPs at both end of the lu User plane access points. The Transport 
Network Control Plane over lu handles the signalling to establish and release the AAL2 call connections. 

7.3.2.2 AAL2 Service Primitives used by the lu UP protocol 

AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in the following table: 

Table 3: AAL2 primitives and parameters 



Primitive 


Type 


Parameters 


Comments 


SSSAR- 
UNITDATA 


Request 


SSSAR-INFO 




SSSAR-UUI 


Not used (Note 1) 


SSSAR- 
UNITDATA 


Indication 


SSSAR-INFO 




SSSAR-UUI 


Not used (Note 1) 



NOTE 1: The setting of this field is set to not used i.e. decimal value 26 according to [8]. 
The primitives of table 3 are the standard primitives of [5]. These primitives are intended to be used in the lu UP. 



7.3.3 GTP-U based Transport Layer 



7.3.3.1 



General 



When the lu UP protocol layer uses the services of a GTP-U transport, it uses an established GTP-U tunnel for 
transferring frames between the GTP-U tunnel endpoints at both end of the lu User plane access points. The RANAP 
Control Plane signalling over lu handles the signalling to establish and release the GTP-U tunnels. 

7.3.3.2 Generic Service Primitives used by the lu UP protocol 

Generic primitives are used at the GTP-U SAP. They are shown in the following table: 

Table 4: Generic primitives and parameters to and from GTP-U layer 



Primitive 


Type 


Parameters 


Comments 


lu-UP-UNITDATA 


Request 


lu-UP-payload 




lu-UP-UNITDATA 


Indication 


lu-UP-payload 





8 



Evolution of lu UP Protocol 



8.1 Principles for Protocol Evolution 



8.1.1 



Unknown field value 



The lu UP protocol may be evolved by taking into use field values that have been specified to be reserved for future use 
or have been specified as spare values. When a UP protocol entity receives an unknown field value, it can react 
differently depending whether the unknown value is reserved for future use or if it is a spare value. The following 
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principles are recommended for receiver reactions : 

If a spare value is used by the sender, but not understood by the receiver, there should be a default action for the 
receiver. This default action should be defined on a field basis. 

If a value that is reserved for future use is used by the sender, but not understood by the receiver, the value 
should be rejected by the receiver. This should be done by sending a Negative Acknowledgement to the peer 
entity, if possible. Otherwise an Error Event should be generated in order to inform the upper layers and the peer 
entity. 

A received Error Event message shall not trigger another Error Event message back to the sender, even though 
e.g. the Cause value in the received Error Event message would not be understood. 

In the following the recommended actions of the receiver are handled field by field when an unknown field value is 
received. 

PDU Type 

Value range: {0-1 in use, 2-13 reserved for future use, 14 in use, 15 reserved for future use}. 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown PDU Type. 

FQC 

Value range: {0-1 in use, 2-3 spare}. 

Recommended action if spare values used: Ignore the field and pass it onwards. 

ACK/NACK 

Value range: {0-2 in use, 3 reserved}. 

Proposed action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed 
about the error event with Cause : Unknown reserved value. 

Procedure Indicator 

Value range: {0-3 in use, 4-15 reserved}. 

Recommended action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown procedure 

Cause Indicator 

Value range: {0 reserved, 1, 16 in use, 2-15 and 17-255 spare}. 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown reserved value. 

Recommended action if spare values used: Ignore the field and pass it onwards. 

8.1 .2 Adding a new field to an existing frame 

If there is a need to add a new field to an existing procedure, the following principles shall be applied: 

The PDU type defines the header mask. Therefore, a new field shall not be added to the header part of an 
existing frame and possible spare bits in the header shall not be taken into use since these would be violations of 
the header mask. 

The Procedure Indicator shall define the fields that should be in a control frame. 

There shall be only one Procedure Indicator for each procedure. 

If a new field needs to be introduced to an existing procedure (i.e. existing procedure that is defined in an 
existing UP version), the new field shall not be added to the payload part. Instead, the new field may be 
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introduced by placing it to a spare field in the payload part of the frame, if possible. 

However, if a new field needs to be introduced to an existing procedure, but spare fields(s) in the payload part 
cannot be used to introduce the new field, then a new procedure shall be created and hence a new Procedure 
Indicator value shall be allocated for the new procedure. 

To enable simple protocol evolution, when a new Procedure Indicator will be introduced, the new frame shall 
include both the new fields and the fields of the old frame. 

When an implementation receives an unknown Procedure Indicator it may use the Error Event message with 
Cause: Unknown procedure to report this. This indicates to the sender that the procedure was not understood and 
it may try with an older procedure. 



8.1 .3 Adding a new PDU type 



In the future, the lu UP protocol may evolve so that there is a need to add a new PDU type. The criteria for introducing 
a new PDU type could be e.g.: 

The Procedure Indicators may run out and there is a need to have more. 

There is a need to change the header mask, e.g. the Frame Number field may need to be increased or the CRC 
field needs to be modified. 

While the PDU type 14 is reserved for future PDU type extensions, there may be 'subtypes' under PDU type 14 in the 
future and there also may be new procedures in these 'subtypes'. 

Thus it has to be ensured that if the same Procedure Indicator value is used under several PDU types, it should be made 
clear e.g. in the Error Event cause element, which PDU type it concerns. 

8.1 .4 Protocol version inandling 

In the future, new versions of the lu UP protocol may be introduced. A reason for a new version of the protocol could 

be, e.g. 

The earlier introduced new features or functions are required to be mandatory in the new version. 

Due to technical development, the new version of the protocol could be totally different (and incompatible) from 
the earlier version. 

The following principles shall be applied to version handling of lu UP protocol: 

It shall be possible to introduce additional modes of operation. 

It shall be possible to evolve the operation modes independently of each other. 

There shall be independent version numbers for each mode of operation. 

The mode of operation of an lu UP protocol instance is decided by the CN, but the version of the mode shall be 
negotiated between the CN and UTRAN during RAB Assignment and Relocation Resource Allocation 
procedures. 

The version number of a UP operation mode may change or be unchanged between different releases. 

When the protocol is evolved it shall be made clear in the specification, which features belong to which versions. 

A new version may be an evolution (i.e. compatible) of the old version or the new version may be totally 
different from the old version. 



Annex A (Informative): 

Illustration of usage of RFCI for AMR speech RAB 

This annex contains information related to usage of RFCIs in the context of AMR speech RAB. 
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The following figure illustrates the RFCI allocation and flow throughout the UTRAN. 
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RAB Attributes: at RAB establishment or reconfiguration, tlie SDU size information parameter is passed 

to UTRAN. Tlie SDU information is organised per BER i.e. RAB sub Flow. For instance,. 12.2 kbits/s AI\/IR 

codec is passed as RAB sub flow 1 SDU size: 81 bits -class A bits-, RAB sub flow 2 SDU size: 103 -class 

B bits, as RAB sub flow 3 SDU size: 60 -class C-), which makes one RAB sub Flow Combination. This is 

done for all rates (i.e. all codec modes, DTX also if included). The lu UP is used in support mode for 

predefined SDU size. 

Allocation of RFCIs: the RNC dynamically allocates an identification (RFCI) to each permitted/possible 

combinations it can offer. E.g. for 12.2. kbits/s, the RNC allocates RFCI 3 (according to the example table 

2) 

Configuration of L2/3 based on RFCIs: RFCIs are used to configure the L23. RLC is used transparently. 

I\/IAC configures its co ordinated DCHs with the RFCIs and associate one RFCI to one TFI 

Initialisation of lu UP: the RNC reports the permitted combinations it can offer to the transcoder using an 

inband lu initialisation frame containing the RFCIs and associated RAB sub Flow sizes. 

Configuration of L2/3 based on e.g. TFCIs: idem as 3. L23 may use e.g. TFI to communicate with the 

Codec about the RAB sub-Flow structure of the SDU received or to be sent. 

RFCIS+ SDU size information: the RFCIs and associated RAB sub Flow sizes are received within the lu 

initialisation frame are passed to the Codec for configuration. 

Example of DL frame transfer: 

The Codec encodes a 12.2 kbits/s frame. It sends down to the lu UP and SDU with an associated RFCI 

equals to 3 (in this example) 

The lu UP packs a frame with a header containing an RFCI set to value 3, and the payload made of the 

SDU received from the Codec. 

The lu UP passes to L23, the lu frame payload (the Codec SDU) and the RFCI. The L23 uses this RFCI to 

break the lu frame onto the co-ordinated DCHs corresponding to the different bits protection classes. The 

corresponding TFI is selected. 

The radio frame is sent with the TFCI chosen by l\/IAC 

The L23 receives the SDUs on the co-ordinated DCHs, combined them back and uses e.g. the TFCI to 

indicate to the codec the structure of the received frame. 



The following table shows RAB sub-flow SDU sizes for a RAB with variable source rate as they are signalled in RAB 
assignment request in RANAP. 
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Table A.I : Example of SDU sizes for AMR with DTX 



RAB sub-flows 


Total size of 
bits/RAB sub- 
flows combi- 
nation 


Source rate 


RAB sub- 
Flow 1 


RAB sub- 
Flow 2 


RAB sub- 
Flow 3 


39 


56 





95 


Source rate 1 


49 


54 





103 


Source rate 2 


55 


63 





118 


Source rate 3 


55 


79 





134 


Source rate 4 


61 


87 





148 


Source rate 5 


75 


84 





159 


Source rate 6 


65 


99 


40 


204 


Source rate 7 


81 


103 


60 


244 


Source rate 8 


39 








39 


Source rate 9 


: 






















Source rate M 



NOTE 1 : In the table above the greyed area shows what is signalled in RANAP RAB establishment request. 

NOTE 2: In the table above the number of sub-flows is informative only. 

SRNC allocates one or more possible/available RAB sub-flow combination(s) and generates RAB sub-flow 
combination set. RAB sub-flow combination number is dynamically generated by SRNC. This RAB sub-flow 
combination set is signalled towards CN with user plane signalling as described in [1]. The signalling towards UE is to 
be defined by TSG-RAN WG2. 

RAB sub-flow combination set 

A RAB sub-flow combination indicator, RFCI, indicates which RAB sub flow combination will be used for the lu user 
frames. In the communication phase the RFCI is included in the user frame, and the RFCI state the structure of the user 
frame. 

Table A.2 below exemplifies the allocation of 4 different RAB sub-flows combinations for 3 sub-flows and generating 
of RAB sub-flows combination set. 

Table A.2: Example of Allocation of RAB sub-flows combination indicator 





RFCI 
(RAB sub- 
Flow 
Combination 
Indicator) 


RAB sub- 
Flow 1 


RAB sub- 
flow 2 


RAB sub- 
flow 3 


Total 


Source rate 


RAB 
sub- 
flows 
combina 
tion set 

















Source rate 1 


1 


39 








39 


Source rate 2 


2 


39 


56 





95 


Source rate 3 


3 


81 


103 


60 


244 


Source rate 4 



NOTE: In the table above the greyed area shows the part that is sent in the initialisation procedure in lu UP. This 
is what constitutes the RAB subflow combination set. 
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Annex B (Informative): 

Illustration of protocol states in the lu UP 

This annex contains information related to possible protocol states for operation of the lu UP. This annex does not 
constraint implementation and is for illustration purposes only. 

The state model is common for both ends of the lu UP so that the protocol machines are operating symmetrically. This 
approach is taken to facilitate state description for all cases including TFO and TrFO. 

Note: Primitive lu-UP-CONFIG-Req is used by upper layers to configure the lu UP protocol layer. It is used in this 
annex for illustrative purposes and therefore it is not defined in chapter 7. 



B.1 Protocol state model for transparent mode 

The following figure illustrates the state model for transparent mode lu UP instances. A transparent mode instance can 
be in one of following states. 

lu-UP-CONFIG-Req 



lu-UP-UNIT-DATA-Req or 
lu-UP-UNIT-DATA-Ind or 
SSSAR-UNITDATA-Req or 
SSSAR-UNITDATA-Ind or 
lu-UP-UNITDATA-Ind or 
lu-UP-UNITDATA-Req 



lu-UP-CONFIG-Req 
Figure: Protocol state model for transparent mode. 



B.1.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and transparent mode data 
transfer ready state is entered. The mode information is received either through RANAP signalling or directly in the CN 
node. In the lu-UP-CONFIG-Req e.g. the following information will be indicated: 

Transparent mode. 

B.1 .2 Transparent Mode Data Transfer Ready State 

In the transparent mode data transfer ready state, transparent mode data can be exchanged between the entities. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 



B.2 Protocol state model for support mode for predefined 
SDU sizes 

The following figure illustrates the state model for support mode lu UP instances. A support mode instance can be in 
one of the following states. 
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lu PDU ► 

Primitive between layers ► 

TBD -► 



lu-UP-CONFIGR&Ek Initialisationjuitialisation 

VRepeat) 

JuiJP^^ONFIGReq / 2 

Initialisation 



First PDU 

received or 

Initialisation 

Ack received 




lu-UP-CONFIGReq 



lu-UP-STATUSIndV 
(Rate control) 



Rate controf 
PDU 



lu-UP-DATAReqor 
lu-UP-DATAInd or 
SSSAR-UNITDATAReq or 
SSSAR-UNITDATAkid or 
lu-UP-UNITDATAkid or 
lu-UP-UNITDATAReq 



Figure: Protocol state model for support mode. 



B.2.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and initialisation state is 
entered. In the lu-UP-CONFIG-Req e.g. the following information could be indicated: 

Support mode for predefined SDU sizes; 

Time alignment (FFS); 

Indication of delivery of erroneous SDUs; 

- Periodicity. 

B.2.2 Initialisation State 

In the initialisation state the instance exchanges initialisation information with its peer lu UP instance. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 

Upon sending or receiving of an initialisation frame the lu UP instance remains in the Initialisation state. The sending 
side starts a supervision timer Tinit- The receiving side acknowledges the initialisation frame with a positive 
acknowledgement or a negative acknowledgement. The lu UP remains in initialisation state. 

Upon reception of an initialisation acknowledgement frame, the supervision timer Tinit is stopped and the lu UP 
instance enters SMpSDU data transfer ready state. 

Upon reception of a first PDU after sending a positive acknowledgement, the lu UP instance enters SMpSDU data 
transfer ready state. 
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Upon reception of an initialisation negative acknowledgement frame (INIT NACK) initialisation frame can be repeated 
n times. 

If after n repetitions, the initialisation procedure is unsuccessfully terminated (due to n negative acknowledgements or 
timer expires) the Error event procedure is used to report the Initialisation failure and the lu UP instance remains in the 
initialisation state. 

B.2.3 Support Mode Data Transfer Ready State 

In the support mode data transfer ready state, support mode data can be exchanged between the peer lu UP instances. 

Upon reception of lu-UP-DATA-Request from the upper layer or SSSAR-UNITDATA-Indication or lu-UP- 
UNITDATA-Indication from TNL layer, appropriate user data transfer procedures are performed. lu UP instance 
remains in the SMpSDU data transfer ready state. 

Upon sending of lu-UP-D ATA- Indication or SSSAR-UNITDATA-Request or lu-UP-UNITDATA-Request the lu UP 
instance remains in the SMpSDU data transfer ready state. 

Upon sending or receiving of a rate control PDU the lu UP instance remains in the SMpSDU data transfer ready state. 

Upon sending of a lu-UP-STATUS -Indication (rate control) the lu UP instance remains in the SMpSDU data transfer 
ready state. 

Upon reception of lu-UP-CONFIG-Req from higher layer the lu UP instance is terminated and the null state is entered. 

Upon detection of a protocol fault, lu-UP-STATUS-Indication is sent to upper layer an error event frame may be sent 
over lu UP. 

TBD event (FFS): In case of handover or relocation, initialisation procedures may have to be performed and lu UP 
instance may have to enter the initialisation state. 
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Annex C (Informative): 
Open Issues of the lu UP 

This annex contains information related to open issues left in the lu UP protocol. 

1) Handling of Abnormal Event and Error Handling; 

2) Timing over lu, including Time Alignment. 
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